Against the dashboard

A dashboard is what you build when you have not decided what matters. It is a way of deferring the decision to the user and calling it flexibility.

Everything on one screen is a cost

The instinct is generous: put it all in front of them, let them choose. In practice a screen of twenty-eight widgets makes the reader do the sorting work every single time they arrive, and they arrive several times a day. You have moved the cost from one decision by you to thousands of small decisions by them.

On the last product I worked on, four widgets accounted for most of the sessions and eleven had never been opened by anyone outside the company. Those eleven were not neutral. They were the noise the other four had to be found in.

Ask what the visit is for

Almost nobody opens an analytics product to browse. They arrive with a question — is anything broken, did the campaign work, why is this number different from last week — and the screen either answers it in a glance or makes them assemble the answer.

Designing for the arriving question means the top of the screen states a conclusion, not a set of inputs. Underneath that, the evidence. Underneath that, the tools for the rarer, more precise questions.

Depth is not the enemy

This is not an argument for taking capability away. Every one of those eleven widgets had a real user somewhere, and the query view we built covers all of them better than a static tile did, because a question asked occasionally deserves to be asked precisely.

The capability moved. It did not leave. That distinction is the whole argument, and it is the one you will have to make repeatedly to the people whose widget got moved.